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Abstract 

1 

This  document  presents  an  investigation  into  the  effective  use 
of  the  ILLIAC  IV  for  information  retrieval.   It  notes  the  lack  of 
parallelism  in  the  10  structure  and  finds  two  orders  of  magnitude  gain 
over  serial  machines  when  using  serial  processing.   It  recommends  serial 
access  methods  and  linearized  structures  where  such  structures  are  possible, 
It  also  recommends  changing  the  ILLIAC  IV  10  structure.  Further,  the 
document  demonstrates  a  linearization  technique  for  graphs. 
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Introduction 

This  report  is  written  to  emphasize  results.  Thus,  conclusions  are 
generally  first  stated,  then  supported.  Gory  support  details  are  relegated 
to  an  appendix,  denoted  as  a  reference  by  a  superscript  capital  letter 

representing  the  appendix  enclosed  within  parentheses,  for  example: 

(D) 
"...can  look  quite  complex. 

Footnotes  and  figures  are  placed  within  the  text  to  avoid  annoying  page- 
flipping.  Bibliographic  references  are  superscript  parenthesized  numbers  and 
may  include  supplementary  comments. 

Figure  1,  following  immediately,  is  not  referenced  directly  in  the 
text,  but  is  included  as  a  piece  of  orientation  information  for  completeness. 
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Summary 

The "ILLIAC  IV  machine  has  been  investigated  with  an  eye  toward 
information  retrieval.  The  results  were  discouraging  at  that  time  and  are 
not  appreciably  better  now.  Because  refinements  to  serial  data  organizations 
are  made  to  allow  simulations  of  conta«t-«dd«ssifc3tfrmem©:ri*i>  it 
was  to  be  expected  that  the  ILLIAC  IV,  which  can  simulate  a  sixty-four 
element  content-addressable-memory,  would  be  precisely  matched  to  information 
processing  and  data  management  problems.  Alas,  the  awkward  input-output 
structure  of  the  ILLIAC  IV  destroys  this  hope.   It  is  frustrating  to  be 
led  ineluctably  to  the  conclusion  that  a  machine  with  such  power  and  speed 
as  the  ILLIAC  IV  is  unsuitably  organized  to  attack  the  single  most  important 
problem  facing  everybody  everywhere;  yet  it  does  seem  to  be  the  case  that 
the  ILLIAC  IV  is  in  fact  not  the  answer  to  information  retrieval  problems 
in  general. 

There  do  exist  two  classes  of  information  retrieval  problems  to  which 
the  ILLIAC  IV  is  suited:   those  problems  which  are  analyses,  breakdowns, 
summaries  or  other  reductive  calculations  including  all  or  most  of  the 
associated  file,  and  problems  whose  data  structures  can  be  linearized  to 
suit  them.  These  may  include  rather  complicated  network  structures,  but 
structural  strictures  are  stringent  with  regard  to  allowable  flexibility 
and  future  utility.  These  structures  must  be  essentially  free  of  loops, 
for  the  price  of  every  loop  included  in  the  final  structure  may  be  a 
very  heavy  retrieval- time  cost. 

A  Voice  from  the  Past 

D.  H.  Lawrie  authored  two  documents   '  concerning  information  retrieval 
using  the  ILLIAC  IV.  One  of  his  general  conclusions  was  that  for  files 
which  had  one  million  entries  (a  number  we  shall  continue  to  use  for 
illustration),  no  type  of  index  table  (hash,  single-linked  or  tree)  could 
be  kept  in  core;  consequently  much  of  the  savings  of  using  such  an 
organization  to  reduce  the  number  of  data  accesses  was  lost  through  the 
offsetting  need  for  index  table  accesses.  "Use  of  binary  trees  affects 


(2) 
(sic)  a  modest  gain...'    observed  Lawrie,  but  his  final  conclusion  was 

considerably  more  discouraging:   "...we  don't  want  to  use  the  ILLIAC  IV 

for  information  retrieval  unless  we  have  to  as  we  don't  achieve  any  great 

(3) 
speed  up  over  a  serial  machine...".   y 

Access  Methods 

There  are  two  types  of  people  in  the  world:   those  who  divide  every- 
thing into  two  groups  and  those  who  do  not.   Those  who  do  will  speak  of 
serial  access  as  opposed  to  all  other  access  modes.   The  author  tends. to 
avoid  this  Aristotelian  viewpoint,  but  this  tendency  to  dichotomize,  turns 
out  to  be  utilitarian  here,  though  we  would  rather  speak  of  static  versus 
dynamic  access  structures. 

Static  access  structures  are  those  in  which  the  elements  of  the 
structure  are  always  accessed  in  the  same  order.   Serial  access  is  the 
prime  (and  possibly  only)  example  of  such  a  structure,  but  it  is  not 
its  serial  quality  but  its  static  quality  which  will  concern  us.   Since 
the  order  of  a  serial  file  is  really  not  relevant  in  the  most  general 
sense  of  serial,  any  ordering  can  be  selected.  This  ordering  is  then 
physically  realized  and  becomes  the  single  order  in  which  the  elements 
are  accessed.  This  is  a  natural  "staticization"  of  the  file,  that  is, 
it  imposes  a  structure  on  the  file  which  allows  static  access  to  be 
meaningful. 

Dynamic  access  structures,  by  contrast,  are  structures  in  which  the 
elements  are  not  accessed  in  the  same  order  every  time  the  file  is  used, 
but  may  be  accessed  in  any  order  depending  on  the  .problem.  Dynamic 
access  methods  depend  (at  least  in  all  their  physical  realizations)  on 
pointers  to  direct  the  dynamic  trace  through  the  file  elements. 

Serial  access  is  the  oldest,  simplest  and  most  straightforward  access 
method  known  to  data  processing.  However,  of  necessity  (being  static), 
access  to  the  file  means  access  to  the  whole  file  .  This  is  wasteful  for 
applications  wherein  only  a  sma.~l.~l  portion  of  the  file  is  (pre)known  to 
be  relevant.   First  attempts  to  overcome  this  problem  centered  on  batching 
of  requests  to  render  larger  portions  of  the  file  relevant,  thus  reducing 
the  percentage  waste  of  a  single  serial  access.   This  refinement,  however, 


remained  too  slow  for  many  applications.  Consequently  a  whole  new  approach 
was  sought.   Several  new  non-serial  access  methods  were  discovered,  though 
it  was  not  really  their  non-seriality  which  was  so  important;  it  was 
their  dynamic  access  structure:   the  elements  could  he  accessed  in  more 
than  one  order,  which  also  implies  that  some  need  not  be  accessed  at  all. 
These  methods  included  index-sequential,  direct  (random,  hashed),  secondary 
indexing,  multi-list,  cellular  multi-list,  file  inversion,  etc.  Regardless 
of  the  theory  of  each  of  these  techniques,  they  all  relied  on  keys  and 
pointers  to  achieve  dynamic  access  structure.  More  complex  problems  were 
now  capable  of  being  represented  too,  since  these  new  access  structures 
could  be  utilized  to  carry  data  .structure;  that  is,  to  show  a  relationship 
between  data  components. 

The  immense  speed  achieved  by  the  parallel  structure  of  the  ILLIAC  IV 
should  be  equally  applicable  to  both  static  and  dynamic  access  structures 
to  achieve  equally  excellent  results;  to  the  extent  that  the  ILLIAC  IV 
is  organized  in  parallel  this  observation  is  true.   It  is  critical  to  note, 
however,  that  the  parallellism  of  the  PE's  (Processing  Elements)  is  not 
maintained  in  the  input-output  (10)  structure  which  causes  a  minimum 
of  sixteen  PE's  to  receive  data  from  a  single  source.  Thus  the  ILLIAC  IV 
is  particularly  inept  (in  comparison  with  its  potential)  at  dealing  with 
keys  and  pointers  rendering  all  previous  dynamically  structured  access 
methods  and  accompanying  expertise  in  them  largely  useless  and  irrelevant. 

Either  an  entirely  new  concept  of  file  organization  must  be  discovered 
or  the  use  of  the  ILLIAC  IV  for  information  retrieval  must  be  suitably 
restricted  if  optimum  efficacy  is  to  be  achieved.   Considering  that  a 

completely  new  file  organization  must  be  invented  merely  to  reap  the 

(k) 
benefits  of  serial  access  on  the  ILLIAC  IV,     it  seems  unwise  to  speak 

of  revolutionary  file  structures  in  the  immediate  future.   Structural 

theoreticians  may  provide  some  assistance  as  familiarity  with  the  ILLIAC 

IV  grows,  but  little  relief  is  apparent  in  the  near  future. 


The  Problem  of  Non-Static  Access  on  the  ILLIAC  IV 

The  10  structure  of  the  ILLIAC  IV  is  such  that  at  least  sixteen  (16) 
PE's  must  be  loaded  from  a  single  data  block.  A  dynamic  access  scheme 
implies  keys  and  direct  pointers  to  desirable  data  blocks  to  minimize 
access  to  unneeded  data,  thereby  holding  waste  to  a  minimum.  Though  each 
PE  in  a  set  of  16  may  compute  independently  which  block  it  should  access 
next,  only  one  of  the  16  blocks  so  determined  can  actually  be  accessed 
at  once;  thus,  the  waste  factor  approaches  15:1  (it  being  possible,  though 
relatively  infrequent,  that  more  than  one  PE  desires  the  same  block). 
Further,  the  effective  10  rate  is  slowed  by  transmitting  only  16  PEM's 
worth  of  data  at  a  time  instead  of  the  full  6k   PEM's  possible  on  each 
data  transfer. 

While  it  may  be  argued  that  a  waste  of  15: 1  is  not  very  large 
compared  to  the  waste  from  serial  access  for  applications  which  require 
access  to  a  miniscule  portion  of  the  file,  it  should  still  be  noted  that 
the  inter-PE  routing  and  swapping  ©f  the  index  tables  in  and  out  of  core 
contributes  significantly  to  the  access  time,  and  that  any  waste  on  a 
machine  as  costly  as  the  ILLIAC  IV  is  cause  for  serious  revaluation. 

Generalizations 

It  is  not  only  information  retrieval  which  suffers  from  the  peculiar 
10  structure;  multi-programming  and  time- sharing  suffer  similarly  since 
data  paging  is  essentially  identical  to  the  non-static  access  problem: 
pages  are  stored  and  retrieved  by  pointers  and  keys,  and  blocks  which  load 
16  PEM's  at  one  time  simply  cannot  be  constructed  as  static  entities  for 
this  type  of  application. 

In  general  we  may  consider  any  process  to  consist  of  three  parts: 

1.  Process  definition 

2.  Core-resident  data 

3»   Peripheral-resident  data 
Under  certain  conditions  (whose  investigation  is  a  topic  in  its  own  right 
and  well  outside  the  concerns  of  this  report)  the  process  definition  can 
be  described  in  such  a  manner  as  to  exploit  parallel  processing.   So  long 
as  the  RGX's  (index  registers)  exist  the  process  can  be  operated  in  parallel, 
even  though  the  core -resident  data  are  different  for  each  PE  causing  the 


need  to  access  different  relative  locations  in  the  PEM's.  But,  if  the 
sequence  of  data  access  from  the  peripherals  is  dynamic  rather  than  static, 
the  data  cannot  be  preformatted  to  utilize  parallellism  with  guaranteed 
efficacy  and  the  process  is  doomed  to  be  relatively  inefficient. 

The  general  conclusion  that  we  may  draw  is  that  any  problem  to  be 
implemented  with  optimum  efficacy  on  the  ILLIAC  IV  must  have  an  access 
structure  which  is  static,  at  least  within  a  16-PEM  block. 

The  following  sections  will  deal  with  demonstrating  the  actual 
efficiency  differences  between  static  and  dynamic  access  structures, 
and  attempts  to  force  apparently  non-static  data  structures  into  a  static 
access  structure. 

Assumptions  and  Definitions 

In  the  following  sections,  formulae  will  be  cited  (and  developed  in 
the  Appendices)  and  typical  numbers  will  be  demonstrated  in  them.   The 
variables  and  their  sample  values  which  are  used  in  these  formulae  are 
defined  below.  The  meaning  of  "[x]"  is  "the  integral  part  of  x",  whereas 
[x]  means  "x  rounded  up". 
Variables  and  values: 

n  =  number  of  records  in  the  file  (one  million,  10 
b  =  buffer  size  per  PEM  in  bytes  (128  words  =  2   bytes) 
a  =  average  buffer-load  time  (U5  milliseconds  maximum) 
d  =  size  of  data  record  in  bytes  (1000  =  10  ~  2  ) 
x  =  size  of  index  record  in  bytes  (16:  value+pointer,  1  word  each) 
t  =  execution  time  of  one  loop  in  computation  (5  microseconds) 
e  =  number  of  PEM's  appearing  as  one  group  (16  or  6k) 
p  =  size  of  value  list,  number  of  entries  in  list  (100) 
Derived  variables: 

m,  =  [b/d]  =  number  of  data  records  per  buffer  per  PEM 
m  =  [b/x]  =  number  of  index  records  per  buffer  per  PEM 

A  — •— M ■ 

M,  =  m,  *e  =  number  of  data  records  per  physical  block 
M  =  m  *e  =  number  of  index  records  per  physical  block 

X      X 


n  =  [n/M,]  =  number  of  physical  data  "blocks  constituting  the  file 

+ 
n.  =  [n.  _/M  ]  =  number  of  physical  index  blocks  at  level  i 

f  =  smallest  number  such  that  (M  )  >n  =  maximum  level  of  index 

x  —  o 

Compute-Time  Considerations 

The  speed  with  which  the  ILLIAC  IV  calculates  suggest  that  the 
limiting  factor  in  information  retrieval  will  most  likely  be  the  10  rate. 
This  is  substantiated  by  the  following  computations. 

The  average  time,  T,  to  check  a  buffer  full  of  records  against  a 
list  of  desired  values  (using  a  binary  search  process)  is: 

T  =  [b/d]*(l-^)*([log2p]+l)*t. 

If  we  presume  some  fixed  value  for  T,  the  amount  of  time  each  PE  has 
to  complete  its  computations,  then  the  larger  [b/d]  and  t  are,  the  smaller 
p  (list  size)  will  be  to  avoid  compute-boundedness.  Assuming 

t  =  5  micro-seconds  and  [b/d]=  10  records-per-buffer 
both  reasonable  and  possibly  generous  figures,  then: 

T  =  50  *  ([logpP]  +  1)  *(1  -  7~)  micro-seconds. 

Since  0  <  p  <  n  then  0  <  T  <  50*([log_p]+l). 

1Q      f\  PO 

For  a  file  of  one  million  records,  since  (2   <  10  <  2  )  then 

0  <  T  <  1  milli-second. 
Thus  if  the  time  available  for  computation  on  a  million-record  file  were 
as  little  as  1  millisecond  per  buffer,  then  the  whole  set  of  unique 
identifiers  for  all  the  file  records  could  be  searched:   p=n=10  is  the 
size  of  the  list  which  generates  a  compute-bound  condition.   Since  the 
identifiers  must  be  at  least  20  bits  in  length,  there  is  not  sufficient 
room  in  core  to  hold  enough  entires  to  cause  compute-boundedness; 
we  run  out  of  space  before  we  run  out  of  time. 

Thus  unless  the  available  compute  time  per  buffer  is  very  small  the 

process  will  be  10  bound.   One-half  millisecond  is  sufficient  to  process 

11 
2  ""  =  20^8  entries.   (Reference  Figure  2  following).   This  is  approximately 

2%   of  the  file  which  is  more  than  we  should  ever  seek  in  this  manner. 

Since  this  many  entries  will  not  take  more  than  half  of  core,  it  is  a 

reasonable  assumption  that  the  process  will  always  be  compute-bound  and 

that  core  space  is  sufficient.* 

*N0TK:   Apparently,  the  current  U096  longwords  are  expected  to  be  expanded  to 
8192  longwords.   This  allows,  for  instance,  2048  words  for  buffer  space,  20^8 
words  scratch  space,  and  I+O96  *  6h   words  instruction  space.   This  should  be 
plenty. 

10 


The  following  graph  demonstrates  a  curve  showing  the  time  needed  ' 
per  buffer  to  search  a  list  whose  size  is  a  fraction  of  the  number  of 
records  (expressed  in  negative  powers  of  2);  on  semi-log  paper  it  would 
be  a  straight  line. 


(Note  the  method  has  the  usual  peculiar  binary  search  characteristic: 
searching  for  1%   of  the  total  number  of  records  takes  about  2/3  of  the  time 
to  search  through  all  100$  of  them. ) 
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FIGURE  2 
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Serial  Access 

The  ILLIAC  IV  can  perform  a  serial  search  utilizing  its  parallellism  , 

to  the  fullest  (since  serial  access  is  inherently  static  access).   Since 

(5) 
a  PE  appears  to  be  of  approximately  the  same  speed  '   as  a  CDC-6600  or  an 

IBM- 360/75 ,   we  can  expect  a  gain  in  speed  equal  to  the  parallelism  of  the 

ILLIAC  IV,  a  factor  of  6h.     Further  promise  lies  in  the  fact  that  the 

speed  of  the  ILLIAC  disc  is  approximately  3  times  faster  than  currently 

popular  discs,  such  as  the  IBM  2311  disc  pack  or  the  RCA  56U. 

Serial  pass  time  is: 

T  =  nQ*a  =  [n/([b/d]*610]*a  =  22°/(210/210*26)*a  =  2lk*&. 

As  noted  earlier,  a,  "being  dependent  on  latency,  buffering  techniques, 
I®-control  communication  times,  and  data  transfer  rates,  is  difficult  to 
estimate.  Assuming  the  worst,  only  one  buffer,  the  slowest  processing 
time  will  be  achieved.  We  assume  the  worst  case  on  everything: 

a  =  k5   milliseconds  =  kO   mils/revolution^  +  5  mils  event-time. 
Under  this  gruesome  set  of  assumptions,  file  pass  time  is  2  *^5  mils,  or 

T  =  12  minutes. 
The  file  in  this  sample  is  about  60  times  the  size  of  a  tape  file,  hence 

T  =  12  seconds  for  a  tape-size  file. 
Using  the  suggested  6  buffers     or  a  buffer  6  times  as  large: 

T  =  2  seconds  for  a  tape-size  file. 
This  is  a  viable  result  -  in  fact  an  impressive  one. 

An  ordinary  machine  would  lose  a  speed  factor  of  6K   from  lack  of 
parallellism  and  another  factor  of  3  from  disc  differences,  for  a  total 
slow-down  factor  of  192.  Thus  we  see  that  the  ILLIAC  IV  is  2  orders  of 
magnitude  faster  than  an  ordinary  machine  of  about  equivalent  electronic 
speed. 

Index- Sequential  Access 

It  has  already  been  noted  that  adequate  core  space  to  hold  enough 
unique  identifiers  to  drive  the  ILLIAC  IV  into  a  compute-bounded  state 
in  searching  for  them  would  be  absurdly  large.   Since  IO-boundedness  is 
the  problem,  we  investigate  methods  of  limiting  10.   Following  tradition 
and  common  sense  we  start  with  the  simplest  such  method,  index- sequential, 
a  full  description  of  which  is  contained  in  Appendix  B.  Basically,  the 
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data  is  indexed  using  keys  and  pointers  to  point  through  index  levels  , 
to  the  exact  data  block  desired.  Thus  to  satisfy  a  request  for  p  records 
requires  reading  only  p  data  records  plus  associated  index  records. 

As  we  have  already  noted,  each  of  a  group  of  16  PE's  can  determine 
which  block  it  would  like  to  have  next,  but  only  one  of  them,  in  general, 
can  be  satisfied  by  the  next  access.  Consequently,  the  parallellism  of 
the  process  is  reduced  from  6k   to  h. 

The  formulae  for  computing  the  number  of  index  blocks  at  a  given 
level  were  displayed  previously.  Using  them  on  our  standard  figures  we 
find  that  only  2  levels  of  indexing  are  necessary,  in  fact  since  only 
one-sixteenth  of  the  second-level  index  block  is  used,  the  file  could  be 
expanded  by  a  factor  of  16,  to  16  million  records,  and  still  use  only 
2  levels  of  indexing.  A  file  this  size  would  use  one -tenth  of  the  laser 
memory. 

Using  the  given  sample  values  in  the  cited  formulae,  the  computations  are: 

Md  =  md*e  =  [b/d]*l6  =  [210/210]*2i+  =  2k 

M  =  m  *e  =  [b/x]*l6  =  [210/24]*2^  =  210 

n*  -  Cn/Md]+=  22V  =  ^ 

"1  "  [no/M/=  2l6/2l°=  *' 

n2  =  [n1/Mxf=   [26/210]  =  [l/l6]  =  1  (f=2). 

The  speed  of  index-sequential  centers  on  minimizing  the  number  of 
disc  accesses  made.  To  deliver  a  single  record  requested  by  its  unique 
identifier  requires  only  3  disc  accesses  (one  at  each  level)  for  a  total 
time  of  only  3*^-5  =  135  milliseconds,  but  most  of  the  machine  is  doing 
absolutely  nothing  at  this  time,  and  considering  its  hourly  cost  ($1000- 
$2000^  ')  it  will  be  expensive  indeed  to  use  so  little  of  it.   One  million 
times  as  many  records  can  be  accessed  in  2  minutes  which  is  only  120  times 
as  long.  This  is  a  h   orders  of  magnitude  loss,  gross  inefficiency. 

To  improve  the  efficiency  requests  may  be  batched.  Assuming  a  batch 
of  100  requests  {-1%   of  the  file)  which  implies  getting  some  extra  usage 
out  of  the  index  accesses  we  can  compute  the  total  time  needed.   The 
level  2  index  block  must  be  accessed,  this  in  turn  will  lead  to  51  level  1 
index  accesses,  and  finally  100  data  accesses.   '  '     Thus  total  access 
time  is  seen  to  be: 

T  =  ([l/i+]++[5l/if]++[lOOA]+)^5  milliseconds  =  1.35  seconds. 
Again,  using  6  buffers:  T  =  .2  seconds 
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Using  index-sequential  we  can  achieve  in  .2  seconds  what  it  would  take  us 
2  seconds  to  achieve  serially  (and  about  7  minutes  on  an  ordinary  machine). 
While  it  may  very  well  be  worthwhile  to  achieve  a  single  order  of  magnitude 
speed-up  over  ordinary  machines,  we  have  already  seen  ways  to  achieve  two 
orders  of  magnitude  improvement.  Consequently,  though  index-sequential 
may  be  of  some  utility,  the  cost/performance  ratio  of  the  ILLIAC  IV 
suggests  the  need  to  concentrate  on  the  area  of  largest  gain  first. 

Other  Non-Static  Access  Methods 

Since  other  non-serial  (non-static)  access  methods  deal  with  multiple 
keys  and  pointers  which  in  general  refer  to  more  than  one  record,  we  can 
visualize  a  rapid  deterioration  in  efficiency  in  attempting  to  employ 
such  structures  for  the  ILLIAC  IV.  With  only  a  shallow  margin  of  speed-up, 
at  best,  realized  from  index- sequential,  the  value  of  multi-keying  is 
highly  questionable. 

While  index- sequential  may  be  useful  as  an  alternate  method  of  access 
to  a  file  processed  mostly  serially,  the  multi-keyed  organizations  may  be 
useful  for  the  extension  of  capability  to  represent  certain  data  structures, 
■whose  pursuit  seems  ill-advised,  at  least  until  the  larger  potential  gains 
are  realized. 

Considering  the  complexity  of  the  subject,  no-figures  will  be 
introduced  here  in  support  of  this  argument.   It  is  clear  from  qualitative 
considerations  alone  that  complex  keying  schemes  are  not  a  very  fruitful 
approach  to  information  retrieval  on  the  ILLIAC  IV. 

New  Data  Organizations 

'  (h) 

It  has  already  been  notedv  '   that  the  records  of  a  file  intended  for 

ILLIAC  IV  serial  processing  must  be  stored  in  a  new  and  very  unusual  way 

to  cause  them  to  appear  in  core  so  that  each  record  is  contained  in  one 

PEM  instead  of  split  across  one  or  more  PEM's.   This  document  assumes  that 

such  an  organization  is  feasible  and  well  understood.   There  are,  of 

course,  practical  and  implement at ional  problems  associated  with  this  new 

structure,  and  the  problem  may  turn  out  to  be  more  complicated  than 

currently  imagined,  but  it  seems  safe  to  assume  that  these  potential 

complications  will  not  be  in  philosophy  but  of  a  more  tractable  order 

of  magnitude,  and  consequently  this  organization,  and  the  process  of 

creating  it  from  standard  files  is  taken  to  be  known. 

We  have  already  determined,  however,  that  any  further  revolutionary 

organization  on  the  ILLIAC  IV  is  not  likely  nearby,  and  that  serial  access 

is  by  far  the  most  efficient  method  of  file  search  on  the  ILLIAC  IV  in 
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comparison  to  other  machines.  It,  therefore,  is  obvious  that  for  maximum 
gain  we  should  address  ourselves  to  discovering  just  what  abstract 
structures  are  vulnerable  to  linearization  (serialization,  staticization) . 

Networks 

It  is  well  known  that  trees  can  be  linearized  in  several  ways. 
Certain  networks  can  also  be  linearized.  The  linearization  process  is, 
to  some  degree,  dependent  on  the  problem  set  for  which  the  data  will 
be  used;  hence,  we  might  say  that  the  network  can  be  custom-linearized 
for  a  process. 

Networks  that  can  be  linearized  have  no  loops.   They  are  directed 
graphs  which,  by  repeating  nodes,  can  be  expanded  into  trees.  Several 
such  trees  may  be  woven  together  if  every  node  common  to  more  than  one 
tree  has  the  same  subtree  in  all  such  trees.   (This  condition  is  in  fact 
more  stringent  than  necessary.   It  is  sufficient  that  the  path  from  a 
given  root  to  a  given  leaf,  which  can  be  expressed  as  an  ordered  n-tuple, 
does  not  violate  an  ordering  defined  by  any  other  such  path.  This  must  be 
true  for  the  entire  collection  of  such  paths.) 

Once  such  a  network  is  linearized  it  can  be  examined  in  a  single 
file  pass,  that  is,  traced  in  a  single  file  pass.   If  the  network  does 
contain  loops  (rings)  it  can  only  be  partially  linearized.  Each  pass 
over  a  loop  requires  re-passing  part  of  the  file.   If  the  loops  are 
infrequent  and  near  the  leaves  of  the  expanded  tree,  the  penalty  of  a 
second  pass  will  be  paid  rarely.   If  the  loops  are  frequent  and  nearer 
the  root,  they  will  often  cause  extra  passes,  and  if  they  are  interwoven 
at  all  they  will  cause  many  extra  passes. 

If  the  whole  file  is  structured  as  a  simple  tree,  a  certain  ordering 
is  implied  for  the  whole  file.   "All  records  at  level  i  will  precede 
records  at  level  j_  for  i<j"  is  such  an  ordering  (with  the  understanding 
that  records  at  the  same  level  will  be  ordered  in  some  fashion  which 
preserves  their  relation  to  superior  records).   Such  a  file  may  seem  atypical. 
In  fact,  the  constraints  imposed  here,  while  sounding  relatively  mild, 
may  leave  the  reader  hard-pressed  to  think  of  a  useful  example  for  which  such 
a  file  is  apropos.   It  turns  out  that  there  is  at  least  one  commercial 
problem,  the  assembly  problem,  which  fits  this  structure  as  though  tailor-made. 
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The  Assembly  Problem 

One  of  the  problems  which  has  been  getting  some  attention  recently  is 
"parts  explosion" :  determining  what  kind  of  components  and  how  many  of 
each  are  needed  to  manufacture  a  certain  assembly  (or  subassembly). 
The  sister  problem  is  the  determination  of  what  can  be  done  with  a  certain 
component  and  how  many  of  them  are  needed  to  do  it.  Files  to  solve  these 
problems  are  set  up  as  bi-lateral  networks  involving  two  pointer  chains: 
the  explosion  chain  and  the  where-used  chain.  The  graph  appears  bi- 
directional because  it  has  forward  and  backward  pointers,  yet  the  application 
is  such  that  only  one  pointer  set  is  used  at  a  time.   Considering  the 
pointer  sets  independently  leads  to  two  orderings,  one  (not  surprisingly) 
being  the  reverse  of  the  other.   Consequently  the  explosion  problem  can 
be  attacked  by  passing  the  file  in  one  direction,  and  the  where-used  problem 
by  passing  it  in  the  reverse  direction. 

Examples  are  shown  in  Appendix  D  after  presentation  of  the  lineari- 
zation scheme  and  demonstration  of  an  outline  of  the  algorithm  for  some  of 
the  processing.   The  figures  accompanying  the  examples  show  that  the 
structures  involved  can  look  quite  complex. 

A  few  side-issues  might  be  noted  here: 

1.  This  discussion  is  directly  relevant  to  the  current  Federal 
office-building  program  (where  can  we  build  what  kind  of 
office  buildings? ) 

2.  It  is  curious  to  note  that  one  representation  method  for 
the  needed  information  is  identical  to  one  for  threshold 
functions. 

Other  Applications 

It  should  be  noted  that  though  many  natural  phenomena  are  described 
recursively  that  every  realization  of  them  ultimately  turns  out  to  be 
finite.   Thus,  so  far  as  we  are  concerned,  it  may  be  possible  to  bring 
many  apparently  untractable  problem  formulations  under  the  yoke  of 
linearization,  and  hence  into  the  domain  of  efficacy  of  the  ILLIAC  IV. 
No  further  detailing  of  such  problems  will  be  attempted  here.   It  is 
sufficient  at  this  time  to  know  that  the  set  of  commercial  applications  of 
the  forced  staticization  type  is  not  empty. 
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Intra-Record  Structure 

The  preceding  portions  of  this  treatise  have  been  concerned  with 
inter -record  structure.  This  is  because  the  peculiar  structure  of  the 
ILLIAC  IV  data  transfer  hardware  causes  some  unusual  results  and  has 
some  unpleasant  consequences  upon  file  structure.  We  have  seen  that  this 
is  due  to  the  fact  that,  even  though  16  PE's  can  decide  which  data  blocks 
they  each  want,  the  reading  of  any  data  block  will  affect  all  16  PE's, 
and  hence  they  cannot  really  operate  in  parallel  (i.e.  independently). 

Inside  the  record,  once  the  data  is  in  core,  the  existence  of  RGX, 
since  it  allows  each  PE  to  access  different  relative  locations  in  its  own 
memory,  allows  processing  to  proceed  in  much  the  manner  we  might  expect, 
viz,  all  6k   processors  can  function  independently.  Thus,  so  long  as 
pointers  are  confined  to  point  within  the  record  in  which  they  occur,  any 
structure  which  can  be  represented  by  pointers  can  be  handled  by  the 
ILLIAC  IV.   Specifically,  if  a  set  of  records  with  a  full-blown  network 
intra-record  structure  is  subjected  to  a  complicated  query  relevant  to 
the  entire  file  (implying  that  a  serial  pass  is  efficient),  then  the 
ILLIAC  IV  can  achieve  its  theoretical  maximum  gain  over  other  machines, 
namely  two  orders  of  magnitude.   This  covers  virtually  all  current 
commercial  data  processing  applications  (payroll,  billing,  personnel 
search,  etc.). 

Conclusions 

The  ILLIAC  IV  machine  and  its  associated  disc  are  extremely  fast 
devices.   On  a  serial  file  pass  they  can  be  expected  to  show  a  gain  of  a 
factor  of  200  over  ordinary  machines.  This  implies  a  pass  of  a  tape- 
sized  file  in  approximately  2  seconds.  This  has  commercial  value. 

The  simplest  types  of  traditional  improvement  over  serial  access, 

namely  indexed-sequential  and  random  (hashed),  were  found  to  be  operable 

at  approximately  one  order  of  magnitude  faster  than  predecessor  machines. 

^ith  jfnore  sophisticated  structures  the  advantage  seems  to  be  lost  altogether. 

Previous  investigations  by  D.  H.  Lawrie  agree  with  this  pessimistic 

(3) 
valuation.'    With  a  gain  of  two  orders  of  magnitude  as  a  potential 
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target,  and  considering  the  cost  of  operating  the  ILLIAC  IV,  it  seems  that 
single-order-of -magnitude  gains  would  be  appropriately  relegated  to  a 
secondary  role. 

Due  to  the  incredibly  fast  serial  access  speed  of  the  ILLIAC  IV, 
ways  were  sought  to  linearize  data  structures  so  that  they  might  then  be 
serially  accessed.   Certain  structures  were  found  to  be  amenable  to  this 
procedure,  both  the  structures  and  procedures  being  detailed  herein. 

Lastly,  we  have  shown  that  both  of  these  solutions,  serial  access  and 
structural  linearization,  have  value  in  that  they  do  have  actual  application 
to  real -world  commercial  problems. 

Recommendations 

This  investigation  has  necessarily  dealt  with  broad  considerations 
and  with  qualitative  results  more  so  than  quantitative  ones.  This  is  because 
this  approach  offered  the  greatest  return  for  time  and  money  invested,  and 
was  in  addition  an  unquestionably  necessary  first  step  in  the  procedure  of 
resolving  the  information  retrieval  question  as  it  pertains  to  the  ILLIAC  IV. 
Hence  the  recommendations  herein  are  necessarily  general. 

1.  Attack  problems  where  serial  access  is  efficient.   This  means 
large  scale  problems  of  data  reduction  such  as  whole-file 
summaries  or  cross-correlations.  A  very  large  set  of  problems 
falls  into  this  class  including  almost  all  current  data  processing. 
Also,  data  compaction  problems  are  of  this  nature  since  by 
definition  they  demand  that  every  record  be  examined. 

2.  Attack  problems  with  linearizable  structures.  The  class  of 
problems  encompassed  by  consideration  of  these  structures  is 
unknown  but  it  is  demonstrably  not  empty. 

3«  Do  not  side  with  the  previous  pessimistic  approach  that  information 
retrieval  in  toto  is  not  a  suitable  pasttime  for  the  ILLIAC  IV. 
Already  enough  has  been  seen  to  demonstrate  that  most  of  the 
current  problems  in  the  commercial  area  are  ready  grist  for  the 
ILLIAC  IV. 
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k.    CHANGE  THE  INFERNAL  10  STRUCTURE!  1 1 

The  peculiar  10  structure  of  the  ILLIAC  IV  is  the  single  and 
sole  source  of  loss  of  efficacy  with  regard  to  any  type  of 
information  retrieval  problem.  If  the  10  structure  were  changed 
to  reflect  the  parallellism  of  the  machine  itself,  great  gains 
could  be  realized.  These  are  difficult  to  catalogue  since  they 
are  so  far-reaching,  but  the  following  can  be  seen  immediately: 

A.  The  value  of  traditional  methods  and  knowledge  will  be 
revivified.  This  has  a  host  of  lovable  ramifications.  Once 
traditional  knowledge  is  applicable  no  wheels  will  have  to 
be  reinvented,  a  great  body  of  literature  and  knowledge  will 
become  relevant,  all  problems  and  structures  currently  known 

to  be  solvable  and  their  methods  of  solution  will  be  immediately 
transferable   (possibly  including  some  that  were  never  practical 
before),  a  speed-up  of  two  orders  of  magnitude  will  be  available 
on  all  known  data  structures,  and  finally,  any  advances  and 
discoveries  made  by  people  working  with  the  ILLIAC  IV  will  be 
composed  of  theoretics  which  are  directly  transferable  to  the 
rest  of  the  industry.   Thus,  the  ILLIAC  IV  will  be  in  line  to 
reap  and  also  to  distribute  benefits  of  knowledge  and  technique, 
instead  of  suffering  from  the  need  to  take  great  pains  in 
recreating,  in  its  own  alien  way,  and  in  an  inconvenient  form, 
all  prior  knowledge,  let  alone  new  concepts. 

B.  All  the  above  applies  equally  to  multi -programming  and  time- 
sharing. 

C.  Loss  due  to  extended  programming  time,  including  direct 
loss  due  to  greater  implementation  time  plus  indirect  cost 
due  to  delay  of  getting  a  new  system  "on  the  air"  will  be 
reduced  when  the  programmer  can  concentrate  on  the  exploitation 
of  parallellism  instead  of  worrying  about  how  to  organize  and 
get  at  the  data. 

D.  It  would  pave  the  way  for  the  high-powered  ILLIAC  IV  and  its 
high-powered  associated  staff  to  attack  the  single  largest 
problem  of  both  commerce  and  research,  in  fact  the  problem, 
data  management  and  information  systems. 
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E.  With  a  suitable  change  in  10  structure,  costs  due  to 

consulting  would  go  down,  and  more  consultants  with  useful 
knowledge  would  exist.  More  literature  and  less  abstruse 
problems  would  allow  for  a  greater  choice  of  consultants 
and  less  frequent  need  to  utilize  them.  Also,  since  the 
problems  would  not  be  unique,  other  institutions  would  be 
working  on  them  as  well,  and  knowledge  rather  than  genius 
would  be  useful  in  attacking  succeeding  problem  areas, 
thus ,. evading  the  need  for  ever  more  ingenious  and  costly 
consulting  help.  As  an  immediate  example  of  saved  consulting 
costs  this  report  can  be  cited,  without  the  strange  10 
structure  of  the  ILLIAC  IV  it  would  have  been  totally  unnecessary. 
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APPENDIX  A 
Derivation  of  Binary  Search  Time  Formula 

If  a  value  is  to  be  checked  against  a  list  of  £  values  (a  list  of 
length  p_)  by  a  binary  search,  the  maximum  number  of  comparisons  necessary 
to  determine  whether  or  not  the  value  is  on  the  list  or  not  is: 

[log2  p]  +  1. 
Hence  the  maximum  time  to  make  the  determination  is: 

([log2  p]+l)*t. 
The  maximum  time  will  be  needed  whenever  the  value  is  not  on  the  list, 
since  all  the  comparisons  will  have  to  be  attempted;  however,  when  the 
value  is  on  the  list,  assume  on  the  average  only  half  the  comparisons 
are  necessary  (specious,  but  it  will  do).  Then  the  probable  time,  T,  to 
find  the  value  or  learn  that  it  is  not  present  is: 

T  =  Prob(value  not  on  list)*  maximum-time 
+  Prob( value  on  list)  *  l/2  *  maximum-time. 

If  there  are  n  possible  values  from  which  the  p  values  on  the  list  were 
selected,  then: 

T  =  ((l-p)*([log2  p]+l)*t)  +  (|*£  *([log2  p]+l)*t) 

or      T  =  (l-|n)  *  ([log2  p]+l)  *  t. 

If  a  buffer  is  to  have  all  the  records  it  holds  checked  against  such  a  list 
and  the  buffer  is  contained  in  a  single  PEM,  "then  the  total  time  to  check 
that  buffer  depends  on  the  number  of  records  in  that  buffer,  Ob/dJ  : 

T  =  [b/d]*(l-2^)*([log2  p]+l)*t. 
T  is  the  time  it  takes  each  PE  to  process  the  records  in  its  PEM  against  the 
list  of  requested  records. 


21 


APPENDIX  B 
Index -Sequential  Access  Structure 
Index-sequential  is  a  file  organization  in  which  logical  data  records 
are  ordered  ascendingly  (the  sequential  aspect)  with  respect  to  the  value 
of  some  field  (the  key)  in  each  record.  Logical  records  are  packed  into 
physical  blocks.  An  ordered  list  is  kept  of  the  highest  value  in  each 
block  (the  index  aspect);  associated  with  each  such  value  is  a  pointer  to 
the  appropriate  block.   Each  such  pair  of  values  (key,  pointer)  is  considered 
to  be  a  logical  index  record.  These  in  turn  are  packed  into  physical 
blocks.   If  more  than  one  such  block  exists,  the  index  blocks  are  themselves 
indexed,  that  is,  an  ordered  list  of  the  highest  key  value  in  each  block 
(and  the  associated  pointer)  is  kept.   Clearly  if  r  index  records  can  fit 
in  a  physical  block,  this  second  index  list  will  be,  at  most,  — th  the 

size  of  the  previous  ones.  This  list  is  in  turn  blocked  and  indexed,  and 
the  process  continues  until  the  list  can  be  contained  in  a  single  block. 
This  must  happen,  since  (l/r)   approaches  0  as  n' gets  large. 

The  index-sequential  method,  then,  clearly  depends  on  a  set  of  primary 
(i.e.  determining  physical  order)  keys  and  associated  pointers.  We  already 
know  that  on  the  ILLIAC  IV  all  pointer  methods  are  doomed,  and  consequently 
that  the  ILLIAC  IV  will  not  be  adequate  to  the  index- sequential  task,  or  at 
least,  not  nearly  so  much  so  as  we  would  like. 
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APPENDIX  C 
Calculation  of  Expected  Number  of  Utilized  Index  Blocks 

The  classical  probability  theory  analogue  to  determining  how  many  of 
the  n  (6U)  index  blocks  are  needed  to  access  the  p  (100)  records  is  the 
"occupancy  problem"  which  deals  with  distributing  £  balls  into  n  urns. 
Under  the  usual  assumptions  of  lack  of  bias  (each  urn  is  an  equally  likely 
receptacle  for  each  ball),  the  expected  number  of  occupied  urns  is :  ^   ' 

E  =n*  (l-(l-(l/n))P) 
Consequently,  the  expected  number  of  index  blocks  needed  by  the  100 
batched  requests  is : 

E  =  2  *(l-(l-(l/2  ))P)  =  51  index  blocks   (out  of  6k) 

E  =  2  *(l-(l-(l/2  ))100  =  16  index  blocks  (out  of  16)    (i|)   ~   0 

E  =  10  *(1-(1-(1/10  ))10°)  =  100  data  blocks. 
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APPENDIX  D 
The  Linearization  Scheme 

The  following  is  an  outline  of  how  to  go  about  linearizing  a  graph  in 
the  suggested  manner. 

1.  Each  node  with  no  fan- in  is  expanded  into  a'  tree. 

2.  The  levels  are  numbered  and  each  participating  element  is  associated 
with  its  maximum  level  number.  Nodes  with  no  fan-out  may  be 
demoted  to  maximum  level.   (Also,  if  necessary,  nodes  with  fan- 
out  only  to  maximum  level  nodes  may  be  demoted  to  maximum-1  level,  etc.) 

3«  The  records  representing  each  node  are  then  ordered  ascendingly 
on  the  assigned  numbers.  If  two  elements  have  the  same  number 
then  their  ordering  with  respect  to  each  other  is  irrelevant 
(denoted  by  enclosure  within  parentheses  -  excluding  this  pair.) 
Example  1 ;  The  graph  of  a  single  assembly. 


Expansion  to  a  tree: 

0 

1 

2 

3 


f     T2        T3 


c  -a 

/K        A, 

b?     T_     f  f        T 

AAA"  >V^     AA  A 

"  T1  T2  T3    T2  T3         c^       3     A  A         A 

C  V  a f      T,     f       42  T^     f  T1  T2  \ 

tC  T 


"2  x3       2   x3 


■2      3 


a'       f    t„  t 


A  A 

f  Tx  T2  T3 


2   x3 


2   A3 


T      T 
i2   i3 


2U 


The  ordering  of  the  records  is  now  seen  to  be 
A  b  g  c  a  d  (f  Tx)  (Tg  T3) 
or,  demoting  T,  : 

A  b  g  c  a  d  f  (Tx  T2  T3). 

The  connecting  links  between  graph  nodes  can  represent  more  than  simply 
connections.  Numbers  can  be  placed  on  them  to  represent  distance,  costs, 
or  other  relational  phenomena.  In  fact  these  numbers  often  give  rise  to 
matrices  such  as  linear  combinations  in  Operations  Research.  This  topic 
deserves  some  expansion  of  its  own,  but  not  here. 

For  the  purpose  of  our  examples,  the  numbers  carried  by  the  arrows 
(though  not  actually  shown  there)  will  represent  the  number  of  subordinate 
components  of  each  type  needed  to  construct  the  superior  node,  i.e.,  one 
instance  of  the  assembly  represented  by  the  superior  node.  These  numbers 
will  be  illustrated  in  the  records  representing  the  file  which  demonstrates 
the  linearization  of  our  example  graphs.   The  records  will  be  shown  in  the 
form: 

IDENTIFIER  :  <number  identif ier>  • . . 
with  all  descriptive  data  pertaining  to  the  particular  component  omitted  from 
our  sample  records. 

The  file  organization  of  Example  1  is  then: 


A:  2a  3b  4c  2d  5T 

b:  3f  2g  UTg  2T3 

g:  2c  3f  hi 

c:  la  2f  3T 

a:  Id  2f 

d:  2f  5T3 

f:  3T2  2T 

Tr 

V 

T  • 

3 
EOF  (End  of  File). 

For  example,  then,  a  is  seen  to  be  composed  of  one  d  and  2-f's. 
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We  now  consider  the  problem  of  discovering  just  how  much  of  everything 
we  need  to  make  one  subassembly  b. 
The  totaling  algorithm: 

1.  Establish  an  accumulator  for  each  relevant  component. 

2.  When  a  component  which  has  an  accumulator  is  read,  multiply  its 
component  definition  numbers  by  the  value  of  its  accumulator  and 
accumulate  those  numbers  to  the  proper  accumulators  ( if  a 
component  is  irrelevant  it  may  be  thought  to  have  a  value  of  0) . 

The  process  is  started  by  establishing  an  accumulator.   It  is  demonstrated 
in  detail  below: 

Accumulators 


Step 
Init 
1 
2 
3 


Record 

A 
b 


b=l   (find  components  needed  to  make  1  b) 
b=l   (A  is  not  relevant,  no  accumulator,  ignore  it) 
b=l:  f=l*3  g=l*2  T2=1*U  To=l*2   (mult  by  b=l) 
b=l  g=2  (mult  by  g=2) 
b=l)   g=2:   c=0+2*2  f =3+2*3  T2=k     T-,=2+2*4  or 


5 

a 

6 

d 

7 

f 

8-10 

T   -T 
1     3 

b=l)   g=2:  c=k     f=9  T2=k     T  =10 

b=l  g=2)  c=k:   a=0+H*l  f=9+U*2  T2=k     1^=10+^*3  or 
b=l  g=2)  c=k:   a=U  f=17  Tg=U  T^=22 
b=l  g=2  c=4)  &=h:   d=0+^*l  f =17+^*2=25  T2=k     T^=22 
>=1  g=2  c=k  &=k)    &=k:      f =25+4*2=33  ^=0+4*5=20  T2=4  T-=22 
[b=l  g=2  c=i+  a=4  d=U)f=33:  T.^20  T2=4+33*3=103  T3=22+33*3=88 
b=l  g=2  c=k  &=h  &=k   f=33  Tx=20  T2=103  T3=88 
Therefore,  an  extended  record  of  b  describing  its  total  composition,  would  be: 

b:   2g  ka   Uc  Ud  33f  20T  103T?  88T~  (excepting  arithmetic  errors,  that  is.) 
To  compute  the  proper  number  of  all  types  of  components  needed  to  construct 
five  A's,  one  would  begin  by  initializing  an  accumulator  for  A  to  5  (A=5)- 
In  the  next  example  we  consider  a  few  trees  woven  together,  though 
each  is  less  complex  than  in  Example  1  to  avoid  obscuring  the  content.   Both 
the  totaling  process  and  the  where-used  accumulation  process  will  be  shown. 
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Example  2 

Graph : 


Expansion  to  trees: 

A  C 

A\     A     A     'A2   A 

i    Tl  T2    T2  r3l        T3        T2  ^3       k    Tl  T2    /     \ 
^*3  *T1T2  T2\       J?     TX 


T      T 
2  i3 


T„  T 


2   ^3 


The  orderings  are  then  seen  to  be : 
A:   c  a  (b  T^)  (Tg  T  ) 

B:        b     (T2  T3) 

C:   c  a  (b  T  )  (T2  T  ) 

The  combined  ordering,  taking  all  three  trees  as  a  single  graph,  or  using 

the  common  ordering  defined  by  the  above  (and  the  demotion  rule  for  terminals) 

gives:         (A  B  C  )   cab  (T-  T«  T  ) 


To  demonstrate  the  where-used  chain,  we  recreate  the  trees  from  the  ground 
up,  assuming  that  all  the  arrows  in  the  graph  point  in  the  reverse  direction 
from  that  in  which  they  are  actually  depicted. 
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k 


A 

A  C 


* 


AC   C 

A 


AA' 


A 

AC 


3 

A  A 

!  AC 


Thus  the  orderings  are  seen  to  be: 
T 


a      c  (A  C) 
b   (a  B)   c  (AC)  equivalently:  b  a  c  (ABC) 
To  (a  B)   c  (A  C)  equivalent  as  above  (demotion  of  terminals  rule) 


•3 


The  combined  ordering  is  then:   (T,  T  T,,)  b  a  c  (A  B  C) . 

This  ordering  is  exactly  the  reverse  of  the  explosion  ordering,  as  sxpected. 
Consequently,  the  explosion  question  can  be  answered  by  a  forward  file  pass 
and  the  where-used  question  by  a  backwards  file  pass.  We  demonstrate  the 
file,  again  including  only  the  composition  information  but  none  of  the  other 
(descriptive)  data  which  may  occur  in  each  record,  such  as  vendor, 
characteristics,  price,  etc.   The  format  is  as  before  with  the  addition 
of  "//"  to  separate  the  explosion  chain  from  the  where-used  chain  and  "*" 
to  terminate  a  record. 
File: 

2a  3b  ^c  5T1  //* 


2b  3T2  //* 
2a  3c  2T2  /J* 

la  3T3  HkC* 


2b 


hl1   3T2  //  c  A  C  * 


2' 


"5  ' 

J 


2T2  3T3  //  a  A  B  * 

II   a  A  * 

II   a  b  B  C  * 
II  "b  c  * 


EOF  (End  of  File) 
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To  find  the  total  for  assembly  CJ  (say  3  assembly  C's) 

Step  Record  Accumulators 

Init  -  C=3 

1-2  A,B  C=3 

3  C  C=3:  a=0+3*2=6  c=0+3*3=9  T2=0+3*2=6 

h  c  (c=3)  c=9:  a=6+9*l=15  Tg=6  T  =0+9*3=27 

5  a  (C=3  c=9)  a=15:  b=0+15*2=30  ^=0+15^=60  T2=6+15*3=51  T3=27 

6  b  (C=3  c=9  a=15)  b=30:  T]_=6o  T2=51+30*2=lll  T3=27+30*3=H7 
7-9  T]_-T3  C=3  c=9  a=15  b=30  T-L=60  T2=lll  T  =117 

Thus  a  super-record  for  C  is  C:   3c  5a  10b  20T   37Tg  39T^ 
Now  we  consider  an  algorithm  for  a  where -used  expansion: 

1.  For  every  relevant  record  found,  annex  its  where -used  list  to 
an  overall  where-used  list. 

2.  For  every  name  on  the  overall  where-used  list  find  its  record  and 
take  a  linear  combination  of  accumulators  with  its  composition. 

The  process  is  initialized  by  establishing  a  counter  for  the  desired 
component  with  a  value  of  1. 

Where-used  expansion  for  Tp  (recall  the  file  is  read  backwards J  is: 

Step  Record  Accumulators  and  list 

Init  -  T2=l 

1  T_  Tp=l   (T-  irrelevant,  has  no  counter) 

2  T  To=1  //  a  b  B  C  (Note  Tp  was  considered  on  the  list) 

3  T,  Tp=l  //  a  b  B  C   (T-,  has  no  counter,  irrelevant) 
k  b  T2=l  b=l*2=2  //  a  B  C   (b=2*T2+3*T3;  Tp=l  T3=0) 

5  a  T2=l  b=2  a=2*2+3*l=7  //  c  A  B  C 

6  c  T2=l  b=2  a=7  c=l*7=7  //ABC 

7  C  T2=l  b=2  a=7  c=7  C=2*7+3*7"t-2*l=37  //  A  B 

8  B  T  =1  b=2  a=7  c=7  C=37  B=2*2=^  //  A 

9  A  T2=l  b=2  a=7  c=7  C=37  B=k  A=2*7+3*2+U*7=53 


Thus  a  super  where -used  record,  describing  how  much  of  component  Tp  is 
required  to  construct  various  assemblies  might  be: 
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T2:  7a  2b  7c  53A.  k-B   37C 
Note  the  figure  for  C:  37*  One  C  can  be  made  using  37  Tp's.  This  agrees  with 
the  expansion  of  C  given  in  this  example:  one  of  the  components  of  C  is 
Tp  and  37  of  them  are  needed. 
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